fix: macOS bigWigToWig fallback + create_sparse value column (5.11.12) - #151
Merged
Merged
Conversation
Reported by a user on macOS (arm64, misha 5.11.10).
1. gtrack.import() of a bigWig cannot work off-Linux: inst/bigWigToWig.tar.gz
contains a single Linux x86-64 binary, so system() just fails and the import
dies with the generic "BigWigToWig conversion failed". get_bigWigToWig_bin()
now resolves in order: options(misha.bigWigToWig), the bundled binary (Linux
only), Sys.which("bigWigToWig"), then an error naming the conda package and
the UCSC download URL. Linux resolution order is unchanged, so no behavior
change there; the option also gives Linux users an escape hatch when the
bundled 2021 binary hits a glibc mismatch.
2. The same report claimed gtrack.create_sparse() misaligns values when
intervals are unsorted. It does not: the C++ side sorts a copy and then
indexes _values through iu.get_orig_interv_idx(), i.e. by the original row
position (GenomeTrackCreateSparse.cpp). Verified on unsorted multi-chrom
input. What actually bit the reporter is gintervals(), which returns its rows
sorted into canonical chrom order while a separately held value vector stays
in the argument order - so the two frames desync before create_sparse ever
sees them.
Rather than warn from gintervals() (it sorts on nearly every call, so the
warning would be noise), make the mismatch unconstructible at the point of
use: values is now optional and falls back to a "value" column of intervals.
Documented the row-order contract on both functions.
Claude-Session: https://claude.ai/code/session_01GCdUQC4k8tf93iHnZHSTVS
There is no bigWig import test at all, so get_bigWigToWig_bin() was never exercised on the macOS CI runner despite macos-latest being in the matrix - which is why the Linux-only bundled binary went unnoticed until a user hit it. Covers all four rungs: the misha.bigWigToWig option, the bundled binary on Linux, PATH lookup off-Linux, and the informative error when nothing is found. Mirrors the existing "bigwig export errors when converter not available" test. get_bigWigToWig_bin() takes sysname as an argument (defaulting to the real one) so the off-Linux branches are testable from Linux. Sys.which() reads PATH directly rather than shelling out, so the not-found branch is exercised by pointing PATH at an empty dir - no mocking needed. Claude-Session: https://claude.ai/code/session_01GCdUQC4k8tf93iHnZHSTVS
test-gvtrack-clear.R was the only test file touching the shared test DB
without calling create_isolated_test_db() first (110 other files do, including
its sibling test-gvtrack.filter.R). It therefore relied on the ambient
.misha$GROOT left in place by setup.R, which is a real order-dependency: under
TESTTHAT_PARALLEL testthat runs several files per worker process, and the
hazard of a sibling repointing GROOT is already documented in
helper-test_db.R:76-87.
Found while chasing a parallel-run failure here ("Interval test.fixedbin does
not exist"). That particular failure turned out to be caused by /tmp being
full - create_isolated_test_db() copies a DB per worker into tempdir() and
does not check the exit status of its cp/ln calls, so a partial copy fails
later with a confusing error. With TMPDIR on a volume with space the suite is
green either way, so this commit fixes the latent inconsistency, not that
failure.
Claude-Session: https://claude.ai/code/session_01GCdUQC4k8tf93iHnZHSTVS
aviezerl
force-pushed
the
fix/macos-bigwig-and-sparse-value-alignment
branch
from
August 3, 2026 13:16
7513d57 to
feafb21
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both issues come from a user report (macOS arm64, misha 5.11.10).
1. bigWig import is broken on non-Linux platforms
inst/bigWigToWig.tar.gzcontains a single Linux x86-64 binary from 2021, so on macOS thesystem()call just fails andgtrack.import()dies with the genericBigWigToWig conversion failed.get_bigWigToWig_bin()now resolves in order:options(misha.bigWigToWig)Sys.which("bigWigToWig")Linux resolution order is unchanged, so no behavior change there. The option also gives Linux users an escape hatch when the bundled 2021 binary hits a glibc mismatch.
Not done: shipping darwin-arm64/x86_64 binaries. That is the friendlier fix but adds two more arch blobs to maintain. Worth revisiting if mac users keep hitting this.
2.
gtrack.create_sparsevalue alignmentThe report claimed
create_sparsemisaligns values when intervals are unsorted. It does not. The C++ side sorts a copy and then indexes_valuesthroughiu.get_orig_interv_idx(), i.e. by original row position (src/GenomeTrackCreateSparse.cpp:116). Verified on unsorted multi-chromosome input.What actually bit the reporter is
gintervals(): it returns rows sorted into canonical chromosome order while a separately held value vector stays in argument order, so the two frames desync beforecreate_sparseever sees them.Rather than warn from
gintervals()(it sorts on nearly every call, so the warning would be noise), the mismatch is now unconstructible at the point of use:valuesis optional and falls back to avaluecolumn ofintervals. The row-order contract is documented on both functions.Tests
New
tests/testthat/test-gtrack.create_sparse-value-alignment.R: unsorted multi-chrom input binds correctly,value-column fallback works, and omitting both errors clearly.